「システム設計の謎を解く」社内読書会#5
こんにちは、たごまさゆきです。
「システム設計の謎を解く」読書会第5回の様子を紹介します。
第5回の様子
今回から第３章です。３．１節から３．３節まで読みました。
第３章は「設計の前にやるべき作業〜共通設計〜」という題がついています。
読書後に議論する前に、「なぜこういったことをやるべきなのか？」をみんなに聞いてみました。
返ってきた答えは、次のようなものがありました。
- 作業の前にメンバーみんなの認識を合わせておくためにやる
- やっておくと後で楽、やらないと後で大変
やっぱりやっておいた方が良さそうだとみんな思っているようです。
その後の議論ではこんな話が出ました。
- Excelの機能一覧だけよりも、図があった方が全体を把握しやすい
- スコープ外の所も含めてシステムの全体像を理解しておくの大事
- 設計上必要であれば、要件定義書を変更する事もあるというのは、なるほどと思った
- サブシステムに分割する意味は？
- 担う機能をはっきりさせて役割を明確にするため
- 疎結合にして、開発をしやすくするため
- アーキテクチャ方針はまず最初にやる
- 標準設計（開発標準を設計する）ということについて
- 設計文書が標準化されていると、書く側だけだけでなく読む側にもメリットがある（後からプロジェクトに参加したメンバーなど）
- 設計書の最適な粒度を決めるのは大変。すっきり決める方法とかあるのかな（それが書いてあるのを期待してしまったがなかった）
- 標準やガイドラインはどのレベルで持つべきか？組織？プロジェクトチーム？
- 当たり前だと思っていたことが、意外とみんな認識が違っていて驚いたことがある
- アレのプロジェクトで作った設計書はなかなかイイ。みんなに共有したい
「標準」は、実は活用するのは難しいという話もしました。
せっかく標準を整備したとしても、使い方を理解していないと効果を出せませんし、形骸化してしまう恐れもあります。
また、標準を維持するコストも実は結構高かったりします。
そのへんも結局バランスなのですが、いかにバランスをとるのか一言だけでは言い表せない難しさがありますね。
次回
次回は8/2（金）に３．４節を読む予定です。
